For many applications, it is desirable for a data processing apparatus to be able to interrupt a current process in which data processing instructions are being executed in order to service another process. While the interrupted process could be terminated entirely and restarted from the beginning once the interrupting process has been serviced, it is desirable to be able to restart the interrupted process from the point at which it was interrupted. In order to achieve this, it is known to copy the contents of a register file storing the current parameters and the current state of the existing process to a stack memory prior to switching to the new process.
A process runs in a context, which is the system state required for the process to run correctly. In the case of an ARM architecture, this state includes the values of certain integer processor registers, including the program counter, stack pointer and link register, and the values of the floating point registers if these are required by the process. Switching between processes therefore requires a switch in the context, including register values, and so a return from an interrupting process to the previous interrupted process therefore requires the preservation and restoration of the context corresponding to the interrupted process.
In the case of a data processing apparatus which provides hardware support by way of dedicated registers only for integer data processing operations, at least some of the integer registers need be preserved in the case of a context switch to service a different process. In the case of a data processing apparatus which additionally provides hardware support for floating point data processing operations by way of dedicated floating point registers, then it is necessary on a context switch to preserve at least some of the floating point registers in addition to the integer registers. This can make it problematic to provide backwards compatibility with code intended to run on a data processing apparatus without hardware support for float operations. The reasons for this are that preserving both the integer registers and the floating point registers would require each process to have sufficient space on its private stack to accommodate the backed up integer and floating point registers, when previously (where hardware floating point support was not provided) the private stacks only needed room to preserve integer registers, and also that the integer and float preservation process significantly increases the interrupt latency compared with the integer only state preservation process of a data processing apparatus without hardware floating point support.